home *** CD-ROM | disk | FTP | other *** search
/ Software of the Month Club 1996 May / Software of the Month Club 1996 May.iso / mac / ISO9660 / ZIPFILES / GIM_313.ZIP / GIMF.DOC < prev    next >
Encoding:
Text File  |  1994-11-05  |  5.0 KB  |  86 lines
  1.           APPENDIX F     THE FUTURE OF GIM
  2.  
  3.  
  4. Appendix A documents some of the changes that have occurred in GIM in
  5. recent months.  These include, for the most part, fixes to bugs that
  6. have been reported, or enhancements that have been suggested, by people
  7. who are using GIM.  We expect that this sort of thing will continue, and
  8. we encourage you to report bugs and to suggest enhancements when you
  9. find them.  We hope you'll discover (as some of our users have told us
  10. <blush>) that we are prompt and responsive when it comes to making these
  11. kinds of changes.
  12.  
  13. However, you may notice from reading Appendix A that none of the changes
  14. that are listed there are particularly ground-breaking, earth-shattering
  15. changes to the fundamental design of GIM.  There are two principal
  16. reasons for this.  The first reason is that GIM (as it stands now) is
  17. fairly stable, and we'd like to keep it that way, and so we'd really
  18. rather not shake things up too much by adding fundamentally different
  19. functionality.  But the second, and more important reason, is that the
  20. next generation of GIM is currently in development, and it is our hope
  21. to include many of the fundamental, structural kinds of changes into
  22. that product.
  23.  
  24. GIM's next generation will involve a major redesign, and we are very
  25. excited about its potential.  The principal goals of that version are:
  26.  
  27.      *  to eliminate the limits that are currently in place.  For
  28.         example, in GIM version 2.xx, a person may only have 12
  29.         marriages, a family may only have 32 children, and a folder may
  30.         have only 32,000 lines of notes altogether.  (There are other
  31.         limits, but these are the ones that we encounter, or have heard
  32.         reported, most often.)  We alleviated this somewhat in version
  33.         3.xx, by increasing the limit of marriages to 24, and the number
  34.         of lines of notes to two billion, but there's no guarantee that
  35.         even these limits won't be encountered by somebody someday.
  36.         Ultimately, we would like to remove all of these limits, and all
  37.         others, making completely lists of persons or lists of families
  38.         that are unbounded.
  39.  
  40.  
  41.      *  to add an unlimited number of events to each person and family.
  42.         For example, the person edit screen currently allows for birth,
  43.         christening, marriage, death, burial, and the four LDS temple
  44.         ordinances, and the family edit screen allows for marriage and
  45.         LDS temple sealings.  But we are very much aware that there are
  46.         many more events that should belong in those screens, including
  47.         things like adoption, immigration, other religious sacraments,
  48.         and so on.  Ultimately, we would like to allow for an unending
  49.         sequence of events for both persons and families, and to allow
  50.         for these events to be from a limitless set of possible events.
  51.         (By doing so, we will also do away with the LDS flavor of both
  52.         of those screens, by making the LDS ordinances one of several
  53.         options, just like any other.)
  54.  
  55.      *  to add an unlimited number of single-line identifiers.  For
  56.         example, the person edit screen currently provides fields for
  57.         Ancestral File Number and Reference Number, and also provides a
  58.         "code" field, all of which may be used as you see a need for
  59.         them.  Brian, for example, uses the Reference Number to record
  60.         U.S. Social Security numbers.  But a better solution would be to
  61.         provide an unlimited number of such identifiers, so that Social
  62.         Security numbers could be recorded in a field called "Social
  63.         Security Number" instead of one called "Reference Number", which
  64.         is really a fuzzy and non-specific term.  The goal is to provide
  65.         identifiers to record not only Social Security numbers, but any
  66.         other descriptors which may be needed, such as "country of
  67.         origin", "native language", "religious affiliation", and so on.
  68.  
  69. Beyond these basic goals, the authors are investigating certain other
  70. improvements which may be of value to GIM's users.  We invite and
  71. encourage suggestions about what structural changes you would like to
  72. see added to GIM, and now is the best time to propose them, now that
  73. we're deep into the design-and-implementation of this next generation
  74. product.
  75.  
  76. Oh, and by the way, this is worth mentioning:  we're planning for this
  77. next generation product to be a native Microsoft Windows application,
  78. written in Borland C++ version 4.0, possibly also including a native DOS
  79. viewer and editor as a secondary effort, to be used in circumstances
  80. where you're doing genealogy on a computer that doesn't "do" MS-Windows.
  81. This DOS viewer-and-editor would include the traversal screen and the
  82. person and family and notes edit screens, but none of the other stuff
  83. (like GIM LISTS and the Prune and Graft Areas).  We mention all of this
  84. so you'll know what we're thinking -- and if you have any thoughts along
  85. these lines, we encourage you to let us know.
  86.